<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
    <title>Clock skew</title>
    <link rel="stylesheet" href="gettingStarted.css" type="text/css" />
    <meta name="generator" content="DocBook XSL Stylesheets V1.73.2" />
    <link rel="start" href="index.html" title="Berkeley DB Programmer's Reference Guide" />
    <link rel="up" href="rep.html" title="Chapter 13.  Berkeley DB Replication" />
    <link rel="prev" href="rep_ryw.html" title="Read your writes consistency" />
    <link rel="next" href="comm_repsites.html" title="Communicating between Replication Manager Sites" />
  </head>
  <body>
    <div xmlns="" class="navheader">
      <div class="libver">
        <p>Library Version 12.1.6.2</p>
      </div>
      <table width="100%" summary="Navigation header">
        <tr>
          <th colspan="3" align="center">Clock skew</th>
        </tr>
        <tr>
          <td width="20%" align="left"><a accesskey="p" href="rep_ryw.html">Prev</a> </td>
          <th width="60%" align="center">Chapter 13.  Berkeley DB Replication </th>
          <td width="20%" align="right"> <a accesskey="n" href="comm_repsites.html">Next</a></td>
        </tr>
      </table>
      <hr />
    </div>
    <div class="sect1" lang="en" xml:lang="en">
      <div class="titlepage">
        <div>
          <div>
            <h2 class="title" style="clear: both"><a id="rep_clock_skew"></a>Clock skew</h2>
          </div>
        </div>
      </div>
      <p>
        Since master leases take into account a timeout that is used
        across all sites in a replication group, leases must also take
        into account any known skew (or drift) between the clocks on
        different machines in the group. The guarantees provided by
        master leases take clock skew into account. Consider a
        replication group where a client's clock is running faster
        than the master's clock and the group has a lease timeout of 5
        seconds. If clock skew is not taken into account, eventually,
        the client will believe that 5 seconds have passed faster than
        the master and that client may then grant its lease to another
        site. Meanwhile, the master site does not believe 5 seconds
        have passed because its clock is slower, and it believes it
        still holds a valid lease grant. For this reason, Berkeley DB
        compensates for clock skew.
    </p>
      <p>
        The master of a group using leases must account for skew in
        case that site has the slowest clock in the group. This
        computation avoids the problem of a master site believing a
        lease grant is valid too long. Clients in a group must account
        for skew in case they have the fastest clock in the group.
        This computation avoids the problem of a client site expiring
        its grant too soon and potentially granting a lease to a
        different site. Berkeley DB uses a conservative computation
        and accounts for clock skew on both sides, yielding a double
        compensation.
    </p>
      <p>
        The <a href="../api_reference/C/repclockskew.html" class="olink">DB_ENV-&gt;rep_set_clockskew()</a> method takes the values for both the
        fastest and slowest clocks in the entire replication group as
        parameters. The values passed in must be the same for all
        sites in the group. If the user knows the maximum clock drift
        of their sites, then those values can be expressed as a
        relative percentage. Or, if the user runs an experiment then
        the actual values can be used.
    </p>
      <p>
        For example, suppose the user knows that there is a maximum
        drift rate of 2% among sites in the group. The user should
        pass in 102 and 100 for the fast and slow clock values
        respectively. That is an unusually large value, so suppose,
        for example, the rate is 0.03% among sites in the group. The
        user should pass in 10003 and 10000 for the fast and slow
        clock values. Those values can be used to express the level of
        precision the user needs.
    </p>
      <p>
        An example of an experiment a user can run to help determine
        skew would be to write a program that started simultaneously
        on all sites in the group. Suppose, after 1 day (86400
        seconds), one site shows 86400 seconds and the other site
        shows it ran faster and it indicates 86460 seconds has passed.
        The user can use 86460 and 86400 for their parameters for the
        fast and slow clock values.
    </p>
      <p>
        Since Berkeley DB is using those fast and slow clock values
        to compute a ratio internally, if the user cannot detect or
        measure any clock skew, then the same value should be passed
        in for both parameters, such as 1 and 1.
    </p>
    </div>
    <div class="navfooter">
      <hr />
      <table width="100%" summary="Navigation footer">
        <tr>
          <td width="40%" align="left"><a accesskey="p" href="rep_ryw.html">Prev</a> </td>
          <td width="20%" align="center">
            <a accesskey="u" href="rep.html">Up</a>
          </td>
          <td width="40%" align="right"> <a accesskey="n" href="comm_repsites.html">Next</a></td>
        </tr>
        <tr>
          <td width="40%" align="left" valign="top">Read your writes consistency </td>
          <td width="20%" align="center">
            <a accesskey="h" href="index.html">Home</a>
          </td>
          <td width="40%" align="right" valign="top"> Communicating between Replication Manager Sites</td>
        </tr>
      </table>
    </div>
  </body>
</html>
